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| Fi the microcomputing literature, one can find a large 
number of papers relating to real-time executives for 
systems based on single microprocessors.!-> However, 
much less is reported about multimicrocomputer 
executives.© Brinch Hansen’ proposed a new language 
concept for concurrent programming, called ‘‘distributed 
processes,’’ which is suitable for real-time applications 
controlled by microcomputer networks with distributed 
- Storage. | 

Here, we describe an executive which is ‘‘tailor-made’’ 
to a specific multimicrocomputer architecture known as 
a task-driven system.® The basic ideas behind the ex- 
ecutive are to use hierarchical control for task schedul- 
ing and to provide interlevel communication via asyn- 
chronous handshake signals. This approach results in a 
highly modular, easy-to-implement executive which can 
be easily adapted to other system architectures.? 


System hardware 


The main feature of a task-driven system is the hierar- 
chical controller which supervises a number of hetero- 
geneous processors, each having private program 
memory, read/write data memory, and some I/O capa- 
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bility. The system may also have global resources that 
include a global data memory used as a message center 
and as a place to store common variables. A simplified 
block diagram of a task-driven system is shown in 
Figure 1. 

The various tasks available to the system are per- 
manently stored in the local program memory of the in- 
dividual processors. When a task is to be executed, it 
needs to be awakened by specifying its starting address 
rather than by being downloaded from central memory. 
Note that some tasks require parameters which have to 
be transmitted with the wake-up signal. In order to avoid 
excessive hardware duplication and restrict the size of the 
local program memory, not all tasks are duplicated in the 
program memories of all processors. However, for 
reliability reasons, and to maintain system performance 
at a specified level, each task is stored in two or more 
local program memories. In order to have complete iden- 
tification, both the task and the processor must be 
specified. 

The duplication of tasks in various program memories 
necessitates the establishment of a fairly long list 
associating the various tasks and processors. To simplify 
the list, each task is assigned the same apparent address 
in each processor which is capable of executing it. A 
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typical processor organization and a profile of its pro- 
gram memory are shown in Figure 2. 


The system executive 


In general, a system can be partitioned into a number 
of units, each of which can be represented by a logical 
abstraction called a process. Each process consists of one 
or more tasks, where a task is considered to be the smallest 
logical entity in the system. This can be represented 
graphically, as shown in Figure 3. 

Whenever one considers the execution of a number of 
processes/tasks, the possibility of data interdependency 
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forces one to define a sequencing relation. Figure 4 in- 
dicates that some processes/tasks can be started at the 
same time (a), while others have to wait until another pro- 
cess/task is either partially executed (b) or completely ex- 
ecuted (c). The simple notation shown in the figure can 
be used to represent the complete sequencing relation of 
any number of processes and/or tasks. 

In a multimicrocomputer system, the executive has to 
maintain an orderly execution of tasks in the most con- 
current fashion possible. The design philosophy behind 
such an executive is different from typical design ap- 
proaches in that it emphasizes simplicity and flexibility 
rather than maximum utilization of resources. Because 
hardware is cheaper than software, one can afford to 
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Figure 1. Simplified block diagram of a task-driven architecture. 
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Figure 2. A typical processor organization and a profile of its program memory. 
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Figure 3. Graphical representation of systems in terms of processes 


and tasks. 
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Figure 4. Graphical representation of process/task sequencing. Some 
processes/tasks can be started at the same time (a), while others have 
to wait until another process/task is either partially executed (b) or 
completely executed (c). 
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underutilize hardware resources in order to obtain the 
desired simplicity and flexibility. To reduce complexity, 
the following restrictions are introduced: 


e Only a few types of tasks are allowed, each with» 
specific interaction capabilities. 

e All communications are done via well-defined logical 
interfaces. 

e Processor allocation is done only by a centralized 
entity. 


To provided maximum flexibility, the executive is de- 


signed according to the following principles: 


e The executive has a multilevel hierarchical structure. 


¢ Communication between levels and within each level 
is done via asynchronous handshake signals. 

e The executive is defined and designed in a modular 
fashion to allow modifications and expansion. 


The executive model consists of two levels: the process 
level, which contains all the relevant information about 
processes, relations, and system parameters; and the task 
level, which maintains information about task relations 
within each process. At the process level, the executive 
utilizes a process manager which, besides controlling the 
process sequencing, accepts requests for service from the 
various task managers operating at the task level and per- 
forms the actual task-to-processor assignment. It also con- 
trols all communication with the external world. At the 
task level, the executive has a number of active task 
managers, one for each currently running process. Each 
task manager controls the actual task sequencing for a 
given process by accepting information from the tasks 
it controls and using that information to initiate new re- 
quests to the process manager. The communication ac- 
tivities between levels and within each level are handled 
via asynchronous handshake signals. The two-level ex- 
ecutive model is shown in Figure 5. 

The process manager itself consists of a two-level 
hierarchical structure. The outer layer of the process 
manager and of the executive is the process sequencer, 
which communicates with the external world. It controls, 
at the process level, all the various activities not directly 
affecting the system hardware. It also transfers to the next 
layer of the process manager the proper information 
regarding the next process to be executed. The inner layer 
of the process manager contains the task allocator, which 
communicates with the system hardware and is respon- 
sible for the task allocation process. It awakens the 
various task managers, transmits the proper parameters 
unique to each process, and controls all subsequent task- 
to-processor assignments. 

Since the actual problems involved in process sequenc- 
ing and task sequencing are exactly the same, we will ex- 
amine only one of the cases. We will consider the task 
sequencing problem, since tasks are the logical entities 
which have to be initiated on the system hardware. This 
will provide insight into various aspects of system 
implementation. 

At the task level there are two distinct types of tasks: 
master tasks and service tasks. The master task is simply 
the task manager having the responsibility to coordinate 
the task sequencing within a given process with the com- 
munications activities associated with it. During system 
operation, the number of active task managers varies ac- 
cording to the number of currently running processes. 
Since the factors which distinguish one process from 
another are the sequencing and specifications of the tasks 
associated with each process, the master task can be a 
general-purpose program which receives from the task 
allocator the parameter specifications unique to each pro- 
cess. In addition to coordinating task sequencing rela- 
tions, the task allocator provides for data passing by 
associating with each task manager ‘‘mailboxes’’ in a 
global memory. Thus, in order to transfer data between 
tasks, one needs only to pass pointers rather than move 
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actual data. In order to enhance system responsiveness, 


the master-task program is included in each processor’s 
local program memory; thus, each individual processor 
can act as a task manager. 

Due to overhead associated with process suspension, 
a master task, once initiated, cannot be temporarily 
suspended. Thus, the processor assigned to it becomes 
dedicated to its execution. However, master task execu- 
tion may be terminated voluntarily based on information 
received from one of its tasks or be aborted by the pro- 
cess manager as a result of external information. The 
master task controls several service tasks, which com- 
municate with it via asynchronous handshake signals. 
Hence, it must be capable of requesting service tasks 
anytime during the course of its execution. 

In contrast to the master task, service tasks are special- 
purpose programs and can be of two types. The majori- 
ty of service tasks are regular tasks which cannot call any 
other tasks during their execution. When the processor 
on which a regular service task is running is required by 
a higher-priority task, the regular service task can be tem- 
porarily suspended (but only once) by the process 
manager and restarted when system conditions permit. 
The other service task type is the privileged service task, 
but in practice only a limited number of them exist. These 
tasks can call only regular service tasks, one at a time. 
To reduce overhead, neither the privileged task nor the 
service tasks which it calls can be temporarily suspended. 
By restricting tasks calls and suspensions in this fashion, 
one avoids nested loops of tasks and thus reduces the pro- 
cessing overhead associated with general multilevel 
suspension. Also, in this way one need not change task 
priority after suspension. However, one needs to associate 


a tag with the privileged tasks, with the regular service - 


tasks called by the privileged tasks, and with the sus- 
pended regular service tasks indicating that they cannot 
be suspended. 

One should note that in the event that a currently run- 
ning task is displaced, control need not be returned to 
the displaced task after the execution of the higher- 
priority task. The next task to be executed is determined 
from a global priority list which varies depending on 
dynamic conditions within the sysm. This list is main- 
tained by the process manager, which also assigns the ap- 
propriate task to an available processor. 


Executive communication protocol. The handshake pro- 
cedure used for the request, assignment, and execution 
of a given task can be described in terms of a communica- 
tion protocol. Although a task manager may request the 
concurrent execution of a number of tasks, for illustrative 
purposes we will examine only the control signals 
associated with a single task. We assume that the Ath task 
manager requests the execution of task 7, and that the 
process manager assigns processor / to execute it. The 
communication protocol is as follows: 


e At time t,, task manager kK initiates a request to the 
process manager, identifying itself and the requested 
task. 

e The process manager, upon receiving the request and 
after a short processing time delay (At), acknowledges 
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Figure 5. Graphical representation of a two-level executive 
model. 


receiving the request. This is done in order to indicate 
to the task manager that its request is being looked 
after and to have some sort of check on the process 
manager. If the task manager does not receive an 
acknowledgment the first time, it repeats its request; 
if again it does not receive an acknowledgment, it 
sends an error message to the process sequencer, 
which is responsible for system diagnostics. 

e After a search time t,, the process manager assigns 
task i to processor / by identifying its apparent start- 
ing address and the task manager which requested it. 

e The process manager notifies task manager k that it 
assigned task i to processor /. This is necessary so 
the task manager will know the processor with which 
it must communicate. 

© Processor j sends a message to task manager X in- 
dicating that it was assigned to execute task i. If this 
signal is not received, the task manager signals the 
process manager to check the processor status. 

e Task manager k specifies to processor / the mailbox 
pointers for data transactions. 

e The task manager k or processor /, or both, signal 
the process manager that execution of task i has been 
started. The process manager may use this signal to 
start a down counter that indicates the remaining time 
for execution. This can be used as additional data 
when deciding which task to suspend and, in the event 
of processor failure, when to reinitiate task execution. 

e Upon completion of the execution of task 7, processor 
j notifies task manager k that it has completed 
execution. | 

e Task manager k signals the process manager that the 
execution of task i has been completed. 


This communication protocol, along with the signals 
used, is shown in Figure 6. 


35. 


to 


TASK MANAGER k 


ty REQUEST SERVICE FOR TASK i 


t, + At REQUEST ACKNOWLEDGED 


PROCESS 
MANAGER 


PROCESSOR /j 


= SEARCH TIME 


EXECUTIVE TASK i FOR TASK MANAGER k 


TASK i WAS ASSIGNED TO PROCESSOR /j 
_—$<$<$<—<$<$ ee 


= EXECUTION TIME OF TASK / 


tz + At PROCESSOR / READY TO START EXECUTION OF TASK / 
ts + At SPECIFY DATA MAIL SLOT IF NEEDED 
te + At EXECUTION OF TASK i HAS JUST STARTED 
ices ee ee —_" 
te 
t7 + te TASK i EXECUTION IS COMPLETED 


PROCESSOR j IS NOT NEEDED 
$e 


Figure 6. Communication protocol used during task call and execution. 


36 


Task interrelations 


Tasks may be classified into two categories according 
to their interdependency and time relationship. The task 
interdependency aspect indicates whether tasks are in- 
dependent or related. Independent tasks can be considered 
separate entities, as each is capable of operating alone 
and does not require the cooperation of other tasks. 
Related tasks, on the other hand, interact with each other 
through cooperation or competition. One should note that 
not all independent tasks can be executed in parallel, as 
their simultaneous execution may involve some sort of 
conflict. However, the order of their execution is irrele- 
vant. Also, not all related tasks need be executed in com- 
pletely sequential fashion. Ideally, in order to achieve 
maximum freedom, one would like to partition the pro- 
cess into a number of independent and parallel tasks 
which can be executed simultaneously. In practice, such 
partitioning is seldom feasible, although one can obtain 
a collection of tasks which permit some form of concur- 
rent execution. | 

Using real-time constraints as a measure of urgency, 
one can classify the various tasks into urgent (time-critical) 
tasks and nonurgent tasks. Urgent tasks always take 
precedence and must be given the immediate attention 


of a processor, whereas nonurgent tasks need not be ex- 
ecuted immediately. Furthermore, within each of these 
groups tasks are assigned various levels of priority based 
on their relative importance and are executed according- 
ly. This permits some tasks to displace a currently run- 
ning nonurgent or lower-priority task, if necessary. 

A state diagram can be used to provide a systematic 
presentation of task interrelations. In a state diagram, 
the states can represent task status, and the state transi- 
tions can be executed under the influence of the proper 
control primitives. All the concepts presented in this sec- 
tion apply equally to process interrelations and can be 
used to define actual process control. 

At any time a task may exist in one of the following 
states: inactive, ready, running, waiting, or suspended. 


e The inactive state is a basic state in the sense that all 
tasks must start and finish in it. The inactive state 
acts as a source for tasks which have not yet been 
scheduled for execution and as a sink for completed 
or aborted tasks. 

e A task is in the ready state if it is able to run, but 
a higher-priority task is running and no other pro- 
cessor capable of executing its code is free. 

e A task is in the running state if it has a processor 
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Figure 7. Complete state transition diagram for the system. 


assigned to it and that processor is executing its code. 
In that sense, it is the only true active state in the 
task execution cycle. 

e A task is in the waiting state during the time that it 
has to await the occurrence of a directly related and 
predefined event. 

e A task is in the suspended state if its execution had 
to be discontinued as a result of system conditions 
unknown to it and not under its control. 


The last two states correspond to temporarily inactive 
states, as no code of the tasks in these states is being ex- 
ecuted. However, some activity takes place on behalf of 
a waiting task, but no activity is directly associated with 
a suspended task. Before a task can be transferred to 
either of these two states, relevant information concern- 
ing the task’s status must be stored. This information can 
be stored either in local memory or in global memory. 
Storing the information in local memory implies that the 
task can be restarted only on a specific processor. This 
increases the contention for the specific processor and 
thus may cause unnecessary delay in the restart of waiting 
or suspended tasks. Storing the information in global 
memory eliminates this problem, since the task can be 
restarted on any appropriate processor, but it can increase 
the contention associated with global memory. However, 
in the implementation we suggest here the suspended state 
is only a transition state, since suspended tasks are 
automatically transferred to the ready state. 

A complete state transition diagram, with all the con- 
trol primitives associated with the system, is shown in 
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Figure 7. The actions associated with the control 
primitives are listed below: 


e WAKE UP—remove task from inactive state. 

¢ RUN—start immediate execution of task. 

¢ COMPLETE—task execution is completed. 

¢ ABORT—return to inactive state. 

e WAIT—relinquish control of processor and store 
relevant information. 

e SUSPEND—relinquish control of processor and 
store relevant information. 

¢ CONTINUE—return to ready state. 


The difference between WAIT and SUSPEND primitives 
is in the type and amount of relevant information that 
must be stored. 


Implementation aspects 


The main role of the executive is to respond in an effi- 
cient manner to various asynchronous service requests by 
assigning the tasks for which the requests were made to 
the appropriate processors. In the design we suggest, the 
executive utilizes a number of look-up tables to control 
task assignment. It makes the actual decisions in a hierar- 
chical fashion according to the contents of the various 
tables. These tables include relevant system information 
and are updated whenever a task changes its status. In 
this sense, one can consider these tables as a set of asyn- 
chronous task-driven lists. This design philosophy 
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matches well the task-driven multimicrocomputer ar- 
chitecture mentioned earlier. The tables, besides 
facilitating control, can also be used to monitor task ex- 
ecution and to provide statistics about system utilization. 

Aside from the simplicity of design, the main strength 
of the executive is the ease of obtaining system verifica- 
tion. Since all task control is based on interrelations 
among the various tables, the complete system operation 
can be simulated as chains of calls and w¢rified prior to 
actual implementation. The simulation can be a general- 
ized procedure, and for each system one needs only to 
provide its unique hardware and operational parame- 
ters—for example, the number of processors along with 
the tasks each one is capable of executing, the estima- 
tion of the time required to execute each task, and the 
proper sequencing relations at each level of the executive. 
The simulation procedure can be used to detect any bot- 
tleneck or sequencing problems. Having determined the 
problems, one can adjust and optimize system perfor- 
mance either by further partitioning critical tasks or by 
using processors with different characteristics. 


Aside from simplicity of design, 
the main strength of the 
executive is the ease of 

obtaining system verification. 


As outlined earlier, the executive is made up of the pro- 
cess manager and task managers. Each task manager is 
a simple general-purpose program whose functions were 
defined previously. The process manager, in turn, includes 
two parts, the process sequencer and the task allocator. 
Here, we shall concentrate on the exact definition of the 
task aijocator since it is the most complex and critical ele- 
ment of the executive. Furthermore, in most of its aspects, 
the process sequencer can be regarded as a simplified ver- 
sion of the task allocator. 


Task allocator. The task allocator subsystem is respon- 
sible for the various activities associated with task assign- 
ment. Considering the required activities, one can iden- 
tify five programs. . 

Task ordering program. In a system, each task may 
assume various priority levels based on its relations to 
other tasks within the same process and on its process 
relation to other processes. Therefore, the task allocator 
must be able to determine the proper ordering of all tasks 
which have to be executed. The task ordering program 
utilizes static information about process relations and task 
priorities as well as currently available dynamic data about 
the system in order to generate the proper ordering of 
the tasks to be executed. The output of this program is 
a list of all tasks to be executed, starting from the highest- 
priority task. In addition, this list—called the ready list— 
also contains various parameters associated with the tasks. 
These parameters are used for control and decision 
purposes. 


Task allocation/communication program. This pro- 
gram handles the various communications activities 
associated with the physical allocation of a task to a pro- 
cessor. It accepts hardware signals and software messages 
from the various task managers as well as from the pro- 
cessor assigned to execute the particular task. It responds 
with the proper control signals. 

Task suspension program. In order to optimize per- 
formance, the decision to suspend a task is made on the 
basis of dynamic information. Whenever a time-critical 
task has to be executed and no appropriate processor is 
free, the task suspension program determines which pro- 
cessors can execute the time-critical task and then forms 
a list of tasks that are candidates for suspension. The pro- 
gram examines each candidate task’s priority and the time 
needed to complete execution of each task, and deter- 
mines the proper task to be suspended. The task alloca- 
tion/communication program uses this information to in- 
itiate the task suspension procedure and perform the 
allocation of the urgent task to the freed processor. 

List updating program. This program is used to main- 
tain all lists used by the task allocator. It updates the ap- 
propriate entries in the relevant tables whenever there is 
a change in the system which affects any of the lists. 

Global memory management program. The task 
allocator stores the relevant information associated with 
the various tasks in a global memory, the content of which 
continuously changes during system operation. The 
memory management program keeps track of this activity 
by maintaining a running file of all unused memory space. 
It assigns available memory to a task when the task alloca- 
tion/communication program requests such memory. The 
latter program signals back to the memory management 
program whenever memory locations become available. 


Lists of the executive. The executive utilizes two types 
of lists: static, which contain basic information which is 
fixed for a given system; and dynamic, which maintain 
running statistics about system operation. Dynamic lists 
can be classified into two categories. The first contains 
all lists which are needed for control purposes. This 
category encompasses the majority of the lists (some of 
which may be used for monitoring purposes). The second 
category includes all lists which are used strictly for 
monitoring purposes, i.e., which are used to get statistical 
information about the system. Lists in this category are 
not used for any control purpose and may be discarded 
without affecting system operation. 

Static lists include the process master list, the task se- 
quencing master list, and the task-processor master list. 

Process master list. This list contains all process se- 
quencing relations, including the relative priorities of the 
processes. It is used by the process manager to generate 
the proper ordering of the processes waiting to be 
executed. 

Task sequencing master list. The proper task sequenc- 
ing relation within each process is listed in this table. 
Whenever a task manager is awakened, the task sequenc- 
ing relations of its process—as listed in this table—are 
transferred to it. 

Task-processor master list. For each task in the system, 
this list includes all the processors that are capable of ex- 
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ecuting it. The apparent starting address, which is the 
same in each processor, is also recorded in this list. After 
finding the next task to be executed, the task allocator 
uses this list to find processors capable of executing that 
task. It also uses the list to locate the task’s apparent start- 
ing address. 

Dynamic lists include the process queue list, the active 
processes list, the task queue list, the ready list, the free 
processor list, the active processor list, the wait list, and 
the suspended list. 

Process queue list. All new requests for process execu- 
tion are placed momentarily in a queue and are subse- 
quently transferred to the various task managers for 
execution. 

Active processes list. This list contains data about 
currently active processes in the system. It is used strict- 
ly for monitoring purposes—it provides information 
about frequency of call for each process. 

Task queue list. The process manager maintains a 
queue associated with the various task execution requests 
arriving from different task managers. The requested 
tasks are listed in their order of arrival along with their 
relative priority within the process and their requesting 
task managers. The task ordering program uses this in- 
formation to place each requested task in the proper 
priority position in the ready list. 

Ready list. As stated earlier, the ready list is generated 
by the task ordering program and lists in order of decreas- 
ing priority all the tasks waiting to be executed. Tasks 
of equal priority are listed in the order of their arrival. 
For each task, the task manager and the urgency level 
are listed. If a task is not time-critical, its ‘‘age’’? must 
also be listed—i.e., whether it is a new task or an old 
(suspended or waiting) one, so it can be restored proper- 
ly. Note that if an old task’s status information was stored 
in a local memory, that task’s respective processor must 
also be listed, since it is the only processor capable of com- 
pleting the task’s execution. 

Free processor list. All currently functional free pro- 
cessors are listed in sequential order. This list is updated 
every time a processor is assigned a task and every time 
a task is either completed or transferred to the waiting 
state. It is used by the task allocator to find a processor 
that is available to execute a specific task. This list may 
also be used to provide statistical information about pro- 
cessor underutilization. 

Active processor list. Each currently active processor, 
along with the specific task it is executing, is listed. This 
list also contains information about whether the task can 
be suspended or not, and about the remaining time for 
execution if it can be suspended. This list is used by the 
task suspension program to determine the task that has 
to be suspended. It can also be used to provide data about 
the actual loading on each processor. This table is up- 
dated whenever there is a change in processor status; it 
is also periodically updated to indicate the change in re- 
maining time for execution. | 

The wait list. For simplicity, the process manager main- 
tains two waiting lists, one based on time delay and the 
other based on event occurrence. Each task’s task 
manager and processor (if the task’s status information 
is stored in a local memory) are listed. Tasks in the time- 
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delay list are listed in ascending order according to wait 
time. For the first task in the list, the absolute delay time 
is listed; for each subsequent task, only the differential 
delay time from the previous task is listed. With this 
technique, only one time measurement counter is needed. 
It is reinitialized every time the task at the top of the list 
is transferred into the ready list. Note that because the 
wait list is an ordered list, each new task must be inserted 
into the proper position. Also, the time differential of 
each task that follows the newly inserted task must be 
readjusted. : 

Tasks in the event list are listed in the order of their 
arrival along with the codes of the events for which they 
are waiting. Event occurrence can be checked either 
periodically or on an interrupt basis. When an event is 
detected, the appropriate task can be transferred into the 
ready list. 

The suspended list. This is a temporary list which con- 
tains in the order of their arrival all the suspended tasks 
not yet processed by the task ordering program. Each 
task’s task manager and processor (if the task’s status 


Although designed for a 
task-driven multimicrocomputer, 
our modular executive can be 
easily adapted to other 
system architectures. 


information is stored in a local memory) are listed. 

With respect to both waiting and suspended tasks, we 
should mention that in order to simplify control each pro- 
cessor has its own save and restore routines. Depending 
on the type and amount of data, different routines may 
be associated with suspended and waiting tasks. These 
routines have the same apparent starting address in all 
processors and are treated as regular service tasks. Each 
task manager holds pointers to either local or global 
memory and transfers them on request to the appropriate 
save or restore routines. 

A flowchart of the task allocation process (Figure 8) 
indicates the usage of the various lists. 


Aithough designed for a task-driven multimicrocom- 
puter, our modular executive can be easily adapted to 
other system architectures. It consists of a two-level 
hierarchical structure comprising a process level and a task 
level. The process level is made up of the process se- 
quencer and the task allocator. The processor sequencer 
is responsible for activities at the process level, such as 
deciding on the next process to be executed, and for com- 
munications with the external world. The task allocator 
is a general-purpose program consisting of five major 
routines; it controls the task allocation process and, by 
doing so, bridges the process level and the task level. At 
the task level there are a number of task managers run- 
ning concurrently, with each responsible for one process. 
Because all task managers are identical and because there 
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is a task manager on each processor, each processor can 
become a task manager. This reduces the possibility of 
a bottleneck associated with finding a free processor to 
act as a task manager. Note that the unique features of 
each process are kept at the process level and are passed 


to the appropriate task managers when they are 
awakened. 

In our design static features unique to the system as 
well as dynamic system conditions are stored in tables. 
The executive utilizes these tables in an interactive fashion 
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FIND APPARENT STARTING 
ADDRESS OF TASK AND 
ASSIGN IT TO PROCESSOR 
(TASK-PROCESSOR LIST) 


DETERMINE TASK TO BE 


PICK NEXT-HIGHEST- 
PRIORITY TASK ON 
READY LIST 


SUSPENDED, USING 
ACTIVE PROCESSOR LIST 


SUSPEND ACTIVE TASK 


INDICATE CONDITION TO 
AND eee TASK ORDERING PROGRAM 


UPDATE READY LIST, 
FREE PROCESSOR LIST, 
AND ACTIVE PROCESSOR 
LIST (LIST UPDATING 
PROGRAM) 


Figure 8. Detailed flowchart of the task allocation procedure. 
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RUNNING CONDITION 


USING READY LIST AND 
APPROPRIATE TASK MANAGER 
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to control the complete system operation. By changing 
the static tables, one can make the system execute new 
processes as long as they are based on tasks that are 
available in the system. For larger systems, one can use 
several of these executives, each controlling its own local 
system, which in turn are controlled by a central unit. 
Process information is prepared by the central unit and 
is then loaded into the proper executive for execution. 
The problem of task segmentation was not considered 
here since it is a major topic in itself. However, in many 
systems one can start with a rough trial task segmenta- 
tion and, by using a simulation procedure as outlined 
here, find system bottlenecks. Using the statistical infor- 
mation from the simulation, one can decide on a second 
task segmentation. These steps can be repeated until ac- 
ceptable system characteristics are obtained. 
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